SPACE 2/SPACE - Library 2 - Volume 1.iso/music/213/comm/update.doc

Text File | 1988-01-12 | 12KB | 265 lines

                  Instructions for Flash 1.51 update file.

There are three files in this archive: UPDATE.DOC, UPDATE.PRG, and
UPDATE.DAT.  You are reading UPDATE.DOC.  UPDATE.PRG and UPDATE.DAT are used
to convert FLASH version 1.51 to version 1.52.  UPDATE will only work with
version 1.51, if you have an earlier version, you can get an update by
sending your original disk to Antic, Attn: FLASH Update, along with $5 for
shipping and handling.

Further on we'll describe the changes in Flash 1.52.  Meanwhile, here's how
to do the upgrade:

Place UPDATE.PRG, UPDATE.DAT, and _a back-up copy_ of FLASH.PRG version 1.51
on the same disk (or in the same folder of a hard disk).  (FLASH.PRG version
1.51 will be exactly 128,268 bytes long.)  Double-click to run UPDATE.PRG;
the update procedure will take a few moments to complete.  When your update
is completed, you should now have an additional file called FLASH152.PRG
that should be 131,924 bytes long.  If you wish, you may rename this to
FLASH.PRG.  Transfer FLASH152.PRG to whichever disk contains your FLASH.RSC
and other working files.  You're all set!

NOTE:  Hang on to your original FLASH 1.51 program in case we upgrade
UPDATE.PRG.

    Flash 1.52 adds some new features to Flash 1.51, including an ARC
command for calling the arc.ttp program directly, the new B-PLUS file
transfer protocol for CompuServe, extra commands for remote operation, and
much faster DO file operation. A few minor bugs are also fixed. The update
program will convert your copy of Flash version 1.51 completely to version
1.52. You use the original Flash 1.51 resource file with the updated
program.

                            FLASH 1.52 Features

      Flash 1.52 is a minor upgrade from the original Flash 1.51. The main
improvements are faster DO files, B-PLUS protocol, extra commands for remote
operation and an ARC command. There are also a number of bug fixes.

 DO file improvements

        I realized suddenly that with a few tricks I could make DO files run
two to three times faster by speeding up the display of commands on the
command line. A feature of this is that during the process of displaying
each command from a DO file on the command line, no input from the serial
port is processed. This is useful so the DO file won't miss any characters
on a WAIT command.

        There is a slight change to the Flash ALERT command. You can now put
an optional  numeric parameter after the variable to indicate the default
exit button that will exit the alert when you press 'return'. e.g.

 >alert "[1][This is an alert][OK|2nd|3rd]" $A 1|

0 is no default exit button, 1,2, or 3 sets the default exit button to the
first, second, or third button.

        Some people want to be able to compare two string variables with the
IFI command, but it failed because in something like:

>IFI $A $B TYPE "SUCCESS"|

$A was being compared to the two letter string '$B' and not the contents of
the variable $B . This was not really a bug, but laziness on my part. This
is now fixed.

        I can't believe I forgot to include a method of getting remote input
into a string variable in Flash 1.51. I have added one new command to fill
this gap:

>GET $X n|

will get a line of input from the serial port into variable $X (or whatever
variable you specify) with a timeout 'n' in seconds, where n is a number
from 1 to 9999. If no timeout is given, the default is two minutes.  Several
people have requested this type of command as they want to try writing their
own remote control DO file.

        To enhance the ability to do remote control access through DO files,
I have adjusted the DDIR [path] [file for output] command so that if you
specify a filename of AUX: for output, the directory will be transmitted out
the serial port, e.g.,

>SEND "Pathname:"|
>GET $A|
>DDIR $A AUX:|

would prompt a remote user for a pathname and then send the directory the
user asked for out the serial port, formatted for 80 columns. Any key (from
remote) pauses, when paused, any key continues.

NOTE: For proper use, I assume that ECHO and LF are ON for the GET command
so that the remote user gets to see what he/she types in properly. If you
want to design a remote user interface using a Flash DO file, use the
commands:

>LF ON|

and

>ECHO ON|

as soon as you get a connection. A recommended method would be:

>WAIT CONNECT|

then test carrier detect with:

>IF CD

If you get a carrier, then turn LF and ECHO on. Warning: if you turn echo on
before the modem has connected, then Flash will echo all modem responses and
you will get nonstop characters.

        Another tiny change I made to enhance remote operation was in the
SEND command. Normally, a '|' in the SEND command gets translated into a
carriage return. In the case that the LF setting is ON, the '|' characters
now gets translated into carriage return + line feed. This would be
convenient if you wanted to send a remote user a menu. Otherwise, with 1.51
you would have to imbed actual carriage return and line feed characters in
the SEND string or waste a string variable by making it equal to carriage
return + line feed. Both these options would be rather annoying.

B-PLUS protocol added

      Flash now has a fairly complete implementation of the B-Plus file
transfer protocol. The improvements over standard B-Protocol and Quick-B are
(1) the use of a CRC checksum for improved error detection and (2) block
send-ahead for faster uploads. B-Plus is indicated during file tranfers by
'B-P+' instead of 'B-P' on the command/status line.

      As far as I know, Flash is the first ST telecom program to include
B-Plus. I have not implemented some features of B-Plus, namely 1K blocks and
extended character quoting. The disadvantages of 1-K blocks on noisy phone
lines appear to outweigh the minor improvement in transfer speed that might
result.

'GEM' command sets path

        When using the GEM command to execute a GEM program, Flash will
automatically switch to the drive and path that the program is located in so
that it can find its resource file properly. When it returns, the path is
set back to the default path.

        I am so used to typing 'cd' for setting default path, instead of the
Flash 'dp' command, that I tend to do it unconsciously. I have adjusted
Flash so  that it recognizes 'cd' the same as 'dp' for those of you who are
used to command shell programs with this syntax..

New 'ARC' command

         I have added 'ARC' as a command in Flash. All you need to do is put
a copy of ARC.TTP in the SAME DRIVE AND FOLDER that you run Flash from.
Flash remembers the drive and folder that it is run from and then will
always use this path to call arc, even if you have changed default paths in
the meantime. Example: if you want to find the contents of the archive
'update.arc', type ARC V UPDATE on the Flash command line.

Other changes

        VT100 fix. Most IBM protocol VT100 convertors seem to draw text on
the screen with cursor positioning commands and hardly ever use carriage
returns and line feeds. This makes a real mess out of the capture buffer,
usually leaving everything on one or two lines. I have added code that will
hopefully add the necessary carriage returns/line feeds as well as
additional spaces if there is a cursor position command in the same row but
different column. This has not been tested very much, but I did not want to
delay releasing Flash 1.52 since only a handful of people requested this
feature. If I have to make further changes to this code, I will release a
revised update patch file. Be sure to save your original Flash 1.51 program
just in case.

Further additions

        In the capture buffer editor, Clr/Home key moves to the beginning of
the buffer, shift-Clr/Home moves to the end of the buffer.

        When you select loading the buffer (from the menu bar) and there is
already text in the buffer, you get an alert box warning you about this, in
case you meant to select MERGE instead.

        Control characters now pass through immediately in type-ahead mode
instead of getting show on the typeahead line as graphics characters.

P.S. If you develop any DO files that use the new GET command or rely on any
of the changes in Flash documented here, please note what version of Flash
is required to use the DO file(s) to avoid frustration.

 Bug fixes

       Yes, there were a couple of bugs in 1.51, fortunately they were not
fatal ones, just minor glitches. For the curious, here are some of the most
noticable bug fixes:

       If a disk error occurred during file transfer, in some cases the
alert box would appear but no mouse cursor. This has [hopefully] been
fixed.
       Nobody ever pointed this one out, but if the buffer was fairly full,
then the line count at the top was not getting updated continuously, but
only if the window slider box moved. Now it updates continuously.
       If someone type DL XM filename from the command line and the file
already existed, then they would get an alert box asking them if they wanted
to cancel the download or not. The bug was that no mouse was present.
       There were some areas where unattended DO files would fail because
alert  boxes would pop up. e.g. XD would not exit from Flash due to the
alert box, if the capture buffer was full, then an alert box would appear
and an alert would appear if the printer wasn't ready. This was more of an
unforseen design flaw than an actual bug.
       These alert boxes will now not appear if a dofile is active. Note
that even in 1.51 the system disk error alerts are turned off during DO
files to avoid DO files getting hung up in them.
       Nobody has ever complained about this, but in echoplex Flash will
echo XON and XOFF [control-q and control-s]. This doesn't cause a problem if
two people with Flash are connected, but could cause a problem with some
programs. So, I have disabled echoing of XON and XOFF in echoplex as a
precaution.
       I have fixed the menu-frozen bug. In 1.51, sometimes the menu bar
wouldn't drop down till you clicked on the mouse button and moved the mouse
a bit. It happened rarely, and only cropped up after you switched from
terminal to capture buffer.
       Some programs exit without closing and deleting windows! This totally
screws up when you go into menu mode and want to fet back into terminal
mode. It's also sloppy programming. Now I check for left over windows after
the EXEC or GEM command and close and delete them.
       Bug in EXEC. It was failing to properly add '.TTP', '.TOS' or '.PRG'
to  program names under certain circumstances. This meant that >EX ARC v
junk| would not work even if ARC.TTP was in the default path. Flash should
have added '.TTP' automatically.
       If you dragged the vertical slider to the top and had a LOT of text
in the buffer, it would not go right to the top, but a few lines below.
Fixed.
       There was an inability to handle long lines for SEND and TYPE
commands in DO files. Now this is changed so you can have up to 100
characters in SEND and TYPE commands in DO files and Flash will process them
properly, even though they are too long to fit on the command line.
       I have also made some minor changes to EXEC function that should
hopefully solve a few wierd incompatiblility problems with programs that
reset clipping or zap the vblank routines.
       There was a bug all along such that when you print a block or the
buffer and the printer is not connected or turned on, the alert warning you
of that would not appear. Fixed.
       I found and fixed a rather obscure bug involving the slider. It
happened if you held down the mouse on the shaded vertical scroller bar
until the slider moved down or up to where the mouse was located. In some
cases, only the top four lines of the screen would be updated and the rest
of the lines would be the previous screen. As soon as you start to type on a
line, it would update with the 'real contents. Note: This was a display
glitch only. It would NOT cause Flash to crash.

              -- Alan Page